fix: don't assume 422 are validation errors#80
Conversation
f887b48 to
df46de8
Compare
There was a problem hiding this comment.
Pull Request Overview
This PR fixes error handling to properly display all UNPROCESSABLE_ENTITY errors instead of assuming they're all validation errors. With the introduction of quotas, 422 status codes can now represent different types of errors beyond validation failures.
- Refactors error output logic to extract and display full error details from API responses
- Changes UNPROCESSABLE_ENTITY error messaging from validation-specific to generic
- Updates error content extraction to use actual response content instead of error string representation
Reviewed Changes
Copilot reviewed 2 out of 2 changed files in this pull request and generated 1 comment.
| File | Description |
|---|---|
| crates/tower-cmd/src/util/apps.rs | Updates error content extraction to use response content instead of error string |
| crates/tower-cmd/src/output.rs | Refactors error handling to display full error details and removes validation-specific messaging |
Tip: Customize your code reviews with copilot-instructions.md. Create the file or learn how to get started.
crates/tower-cmd/src/output.rs
Outdated
| } | ||
| } | ||
| } | ||
| error("The request was syntactically correct, but the Tower API couldn't process it."); |
There was a problem hiding this comment.
This error message is confusing because 'syntactically correct' typically refers to syntax parsing, but UNPROCESSABLE_ENTITY (422) usually means the request was well-formed but semantically invalid. Consider a clearer message like 'The request could not be processed due to semantic errors or business rule violations.'
| error("The request was syntactically correct, but the Tower API couldn't process it."); | |
| error("The request could not be processed due to semantic errors or business rule violations."); |
There was a problem hiding this comment.
I'm ok with changing this I guess. Tower hivemind drop your opinion as well...
df46de8 to
c277051
Compare
bradhe
left a comment
There was a problem hiding this comment.
Discussed on a Hangout and this approach will work well for now!
Until now, all UNPROCESSABLE_ENTITY errors were assumed to be validation errors. With quotas, that's no longer true.
We need to change the way we process errors a bit.
Example: